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BACKGROUND OF THE INVENTION 

The present invention relates to telecommunications systems, and in 
particular, to a combined Telephony-over-Local Area Network (LAN) and 
Private Branch Exchange (PBX) systems. 

Telephony-over-LAN (ToL) systems employing the H.323 protocol for 
communications are becoming increasingly popular as replacements for PBX- 
based telephony systems. However, replacement is not typically ocpurring in 
a single step. Instead, ToL systems are typically connected to a PBX 
because companies do not wish to replace an entire phone system overnight. 
Accordingly, users on the PBX are typically migrated to the ToL system as 
they develop a need, for example, for advanced collaboration and video 
applications. In the interim, telephony users on a LAN may be served by an 
H.323 gatekeeper and may co-exist with telephony users using a digital or 
analog telephone on the PBX served by the PBX. 

In addition, a new class of PBX user, referred to colloquially as "Glass 
Phones", is emerging. The Glass Phone user device is attached to the LAN, 
but is typically not H.323 compliant and gets its call-processing functions from 
the PBX. The Glass Phone user device is typically installed on the LAN either 
for wiring convenience or to allow use of PC Glass Phone software which has 
a convenient user interface, or to avoid the expense of purchasing a separate 
phone for someone who already has a personal computer. 

The Glass Phone feature, also known as Telephony Feature Access 
(TFA), has evolved over the last few years before ToL systems, and as such, 
when a ToL system is connected there may already be some TFA users on 
the LAN. Prior to ToL systems being introduced, Glass Phone calls were 
assumed to be the only real-time traffic on the LAN and did not need to report 
to any policy authority other than the TFA gateway in the PBX. Today, there 
is still no reporting requirement for Glass Phones to any policy authority other 
than the TFA gateway. 

A difficulty with having both TFA and H.323 clients on the same LAN is 
that both types of clients use bandwidth while the H.323 gatekeeper, aware of 
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H.323 clients use of network bandwidth, is unaware that the network's 
bandwidth is being reduced by any active TFA clients. That is, the H.323 
gatekeeper provides a mechanism for enforcing calls for the ToL clients on a 
policy basis, but TFA clients can normally place calls without regard to this 
5 policy. Therefore, the H.323 gatekeeper may unknowingly oversubscribe the 
network by accepting call reservations beyond the available bandwidth. The 
H.323 gatekeeper provides a mechanism for enforcing policy-based calls for 
the ToL clients, but TFA clients can normally place calls without regard to this 
policy. Leaving the H.323 gatekeeper without information on TFA client use 
10 of bandwidth may result in improper bandwidth allocation and in sub-standard 
or no telephony service over the LAN for some users. 

SUMMARY OF THE INVENTION 

These problems in the prior art are overcome in large part by a system 
and methods according to the present invention. In particular, a combined 

15 ToL/PBX system is provided whereby a single policy may be enforced for 
both TFA and ToL users by making the H.323 gatekeeper aware of those 
TFA connections so as to accurately allocate the remaining available 
bandwidth. According to one embodiment of the invention, the ToL 
gatekeeper is at least notified whenever a TFA call is being made or received. 

20 In another embodiment, the ToL gatekeeper interacts with the Glass Phone 
software or with the TFA gateway in the PBX to allow a requested call based 
on bandwidth sufficiency. 

These and other specific embodiments are described in detail below in 
conjunction with the following drawings. 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a diagram illustrating a combined ToL/PBX system according 
to an embodiment of the present invention; 

FIG. 2 is a block diagram illustrating a PBX according to an 
embodiment of the present invention; 
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FIG. 3 is a block diagram illustrating a ToL gatekeeper according to an 
embodiment of the present invention; 

FIG. 4 is a flowchart illustrating call request operation according to an 
embodiment of the present invention; 
5 FIG. 5 is a diagram illustrating call flow according to the embodiment of 

FIG. 4; 

FIG. 6 is a flowchart illustrating call request setup according to an 
alternate embodiment of the present invention; 

FIG. 7 is a diagram illustrating call flow according to the embodiment of 

10 FIG. 6; 

p FIG. 8 is a flowchart illustrating call request setup according to another 

2 embodiment of the present invention; 

W FIG. 9 is a diagram illustrating call flow according to the embodiment of 

P FIG. 8; 

fy 15 FIG. 10 is a flowchart illustrating call setup according to yet another 

embodiment of the present invention; and 
^ FIG. 1 1 is a diagram illustrating call flow according to the embodiment 

3 of FIG. 10. 

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS 
20 OF THE INVENTION 

FIG. 1 is a diagram illustrating a combined ToLVPBX system 100 
according to an embodiment of the present invention. In particular, the 
combined ToL/PBX system 100 includes a local area network 104. A ToL 
server 102 and a PBX 1 14 are coupled to the LAN 104. The ToL server 102 

25 performs switching and control functions and traditional LAN server functions. 
Also coupled to the local area network 104 may be one or more computers 
1 06, 108, 110 and one or more telephony devices 112. The telephony device 
112 may be an H.323 telephone and the computers 108, 110 may include 
expansion boards for communicating using the H.323 standard over the LAN 

30 104. In addition, the computer 106 may be a TFA-compatible computer. 
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Thus, computer 106 may include "Glass Phone" or TFA client software 107 to 
provide a user interface for telephony applications, though call processing 
functions are carried out by the PBX 114 instead of the ToL server 102. PBX 
114 includes a telephony feature access (TFA) control unit or gateway 120 
5 according to the present invention. As will be discussed in greater detail 

below, PBX 114 also interfaces with known telephones 116, 118, which may 
be digital or analog telephones or other telephony devices such as fax 
machines and the like. Both PBX 114 and ToL server 102 provide 
interconnection to a circuit switched network such as the public switched 
10 telephone network or ISDN network. 

FIG. 2 is a block diagram illustrating a PBX 114 according to an 
O embodiment of the present invention. In particular, the PBX 114 includes a 

M switching unit 204 controlled by a central processing unit 200, which is 

S coupled to a memory 202. The switching unit 204, in turn, is coupled to a 

^ 15 voice interface 208, a data interface 210 and a trunk interface 212. The voice 
nJ interface 208 interfaces the switching unit 204 to internal voice lines and 

M telephony devices such as telephones 116, 118 (FIG. 1). The data interface 

S 210 interfaces the switching unit 204 with the local area network 104 (FIG. 1). 

'"^ The trunk interface 212 interfaces to the public switched telephone network or 

ra 20 the ISDN network. A line scanner 206 monitors the voice and data lines, as 
well as the trunk interface for activity in a known manner. Also included in the 
PBX 1 14 is a TFA gateway 120 according to the present invention. The TFA 
gateway 120 is coupled, as will be described in greater detail below, to 
receive telephony requests from the Glass Phone computer 106 and interface 
25 to the public switched telephone network. The TFA gateway 120 is further 
configured to communicate with the gatekeeper 103 of the ToL server 102. 

In accordance with an embodiment of the present invention, FIG. 3 is a 
diagram of the ToL sen/er 102 shown in greater detail. In particular, the ToL 
server 102 may include an H.323 gatekeeper 103, which includes a control 
30 unit 153 and a memory unit 151, and an H.323 gateway 105. As is known, 
the gateway 105 provides a translation function between H.323 conferencing 
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and other non-H.323 terminal types, including translation between 
transmission formats and communications procedures. The gateway 105 
also translates between audio and video codecs and performs call setup and 
clearing on both the LAN side and the circuit switched network side. The 
5 H.323 gatekeeper 103 acts as the central point for calls and provides call 
control services such as address translation from LAN aliases for terminals 
and gateways to IP or IPX addresses (as defined in the RAS specification), as 
well as bandwidth management which is also designated within RAS. The 
H.323 gatekeeper 103 thus can refuse to make any more connections once a 

10 threshold number of simultaneous conferences on LAN 104 is met. The 

effect is to limit the total conferencing bandwidth to some fraction of the total 
bandwidth available. In particular, according to the present invention, the 
H.323 gatekeeper 103 can send and receive bandwidth availability messages 
to and from the TFA interface and/or client software on the Glass Phone or 

15 TFA client computer as will be discussed in greater detail below. 

According to a specific embodiment of the invention, when a TFA client 
107 sends a call request to the TFA gateway 120, the TFA gateway 120 
notifies the gatekeeper 103 of the call request. The gatekeeper 103 then 
determines whether bandwidth is available for the call. If it is, the call goes 

20 through. If not, the gatekeeper 103 informs the TFA gateway 120 that the call 
is refused. The TFA gateway 120 then provides, for example, a fast busy 
tone to the TFA client 107. Turning now to FIG. 4, a flowchart 400 illustrating 
call setup procedures according to this embodiment of the present invention 
is illustrated. Call procedures are also illustrated schematically in FIG. 5. In 

25 the embodiment illustrated, call setup bandwidth communications take place 
between the H.323 gatekeeper 103 and the TFA gateway 120. 

As seen in FIGS. 4 and 5, in a step 402 a call request is sent by the 
Glass Phone or TFA client software 107 of the computer 106. The call 
request is sent via the LAN 104 to the PBX 114, and in particular, is received 

30 by the TFA gateway 120. In step 404, the TFA gateway 120 sends a 

message via the LAN 104 to the gatekeeper 103 of the ToL server 102. 
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Generally, the call request may be a protocol element P (FIG. 5) and may 
include the identity of the caller and its class of service. This message may 
take the form of an admission request (ARQ) message according to the 
H.323 standard (The ARQ message may also include an identification 
5 indicating that a TFA client has made the request). In a step 406, the 

gatekeeper 103 reads the P (or ARQ) message, including identity and class 
of service. In a step 408, the gatekeeper 103 accesses a bandwidth 
database (e.g., stored in the memory 151) (FIG. 3) to determine the priority of 
the call based on the class of service. Generally, if the bandwidth is 

10 available, the gatekeeper 103 will log the call in its list of active calls and 

respond to the TFA gateway 120 with an admission confirm (ACF) message 
(or a more general acknowledgement message A (FIG. 5). If the bandwidth is 
not available, the gatekeeper 103 will respond with an admission reject (ARJ) 
message to the TFA gateway 120. Thus, in a step 410, the gatekeeper 103 

15 accesses the database in memory 151 to determine whether the bandwidth is 
available. In a step 412, if bandwidth is not available, the gatekeeper 103 
issues the ARJ or reject message to the TFA gateway 120, which provides a 
corresponding signal to the TFA user. If, however, the bandwidth is available, 
then in a step 414, the gatekeeper 103 will log the call (including bandwidth 

20 expected to be used). In a step 416, the gatekeeper 103 then sends the ACF 
(or acknowledge A in FIG. 5) message to the TFA gateway 120. In a step 
418, the call is completed in the normal fashion, and in a step 420 the call 
may be terminated by either the caller or the called party. When the call is 
terminated, the TFA client 120 in step 422 will send a termination message D 

25 (or disengage request (DRQ) message) to inform the gatekeeper 103 that the 
call is being terminated and bandwidth is available. (Similarly, the TFA 
gateway 120 will provide the termination message D to the gatekeeper 103 if 
the call is unable to be completed on the PBX side). 

In an alternate embodiment, the TFA client 107 directly informs the 

30 gatekeeper 103 of the call, but for simplicity, the gatekeeper 103 is not 
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permitted to reject the TFA client call. This embodiment is illustrated in FIGS. 
6 and 7. 

In particular, a flowchart illustrating this embodiment of the present 
invention is shown in FIG. 6. FIG. 7 illustrates schematically the call 
5 procedures of FIG. 6. In a step 502, the computer 106's Glass Phone or TFA 
client software 107 of computer 106 sends a call request over the LAN 104 to 
the TFA gateway 120 (FIG. 7). Immediately thereafter (step 504), the TFA 
gateway 120 notifies the gatekeeper 103 via a message N (FIG. 7) that a TFA 
call is being made and will be occupying LAN bandwidth. This N message 
10 may take the form, for example, of a standard control message which 

identifies the call as originating from a TFA client user. In a step 506, the 

y gatekeeper 103 updates its bandwidth calculation and determination, but in 

^ this embodiment does not abort the TFA telephone call. However, for 

subsequent H.323 call requests the gatekeeper 103 will be able to take into 

^ 15 account the bandwidth requirement of the call made by the Glass Phone or 
TFA client software 107 in the determination of the available bandwidth for 

N= other calls. 

n For example, in a step 508, an H.323 client 112 attempts to make a 

call. The gatekeeper 103 accesses its bandwidth database to determine if 

ffl 20 bandwidth is available (step 510). If bandwidth is determined to be available 
in view of the TFA call as well as other calls that may be occurring, the 
requested H.323 call is connected (step 514); and the bandwidth database is 
updated by gatekeeper 103 to account for the H.323 call bandwidth 
requirement If in step 510 sufficient bandwidth is not available for the H.323 
25 call, then an error or reject message is sent by gatekeeper 103 to H.323 client 
112. Next, when in a step 516 the TFA client 107*s call is completed and then 
terminated by either the calling or called party, in a step 518 the TFA gateway 
120 sends a termination message T to the gatekeeper 103. In a step 520, 
the gatekeeper 103 updates its bandwidth database accordingly to indicate 
30 the termination of the TFA call and the availability of the bandwidth used by 
the now-terminated TFA call. 



In the embodiments discussed above (FIGS. 4-7), the TFA client 120 is 
unaware of the H,323 call processing procedures. Another approach, 
however, is for the TFA client 120 to be H.323 capable, but still receive call 
processing features/functions from the PBX. Thus, in such an alternate 
embodiment, the TFA client 107 informs the gatekeeper 103 of the call, and 
the gatekeeper 103 can send a message to the TFA gateway 120 to abort the 
call. This embodiment is illustrated in FIGS. 8 and 9. 

In particular, as shown in FIG. 8, a call request from the TFA client 107 
is made to the TFA gateway 120 (FIG. 9) in step 802. In a step 804, the TFA 
client 107 also informs the gatekeeper 103, for example, by providing a 
protocol element N (e.g., an ARQ message) to the gatekeeper 103. In 
response, in a step 806, the gatekeeper 103 accesses its database 151 to 
determine whether the call is allowable. In a step 808, the gatekeeper 103 
determines whether to allow the call based on bandwidth availability. If the 
gatekeeper 103 determines that the call is allowable, then in a step 810 a 
message A (such as an ACF message) is provided to the TFA gateway 120, 
and gatekeeper 103 logs the call and bandwidth requirements in its database. 
The TFA gateway 120 then completes the call in a step 814. Once the call is 
completed and then terminated by either the calling or called party, in a step 
814 the TFA client 107 sends a termination message T (e.g., DRQ) to the 
gatekeeper 103 (step 816). Gatekeeper 103 then updates its database 151 
to account for the call termination. If, however, in step 808 bandwidth was 
determined not to be available, in a step 812 the gatekeeper 103 sends a 
reject message R (e.g., ARJ) to the TFA gateway 120. The TFA gateway 120 
then provides, for example, an error signal to the TFA client 107. 

According to yet another alternate embodiment, in which the TFA client 
107 may be H.323 compatible, the TFA client 107 sends call requests initially 
to the gatekeeper 103. The gatekeeper 103 then determines whether or not 
the call can be connected based on the available bandwidth. If the call can 
be connected, gatekeeper 103 sends a message to the TFA client 107. The 
TFA client 107 is then free to make a call request to the TFA gateway 120. 



Once the call is completed, the TFA client 107 sends a message to the 
gatekeeper 103 so that the gatekeeper can update its database. This 
embodiment is shown in FIGS. 1 0 and 11. 

In particular, as shown in FIG. 10, in a step 1000 the TFA client 107 
sends a call request to the gatekeeper 103. The call request may be a 
standard H.323 request or another protocol element which identifies the TFA 
client 107 as a TFA client. In a step 1002, the gatekeeper 103 accesses its 
database 151 to determine whether the call can be completed based on the 
available bandwidth. In a step 1004, the gatekeeper 103 makes the 
bandwidth determination. If sufficient bandwidth is available, then in a step 
1006, the gatekeeper 103 sends an ACCEPT message to the TFA client 107. 
The TFA client 107 then makes a call request to the TFA gateway 120 in a 
step 1010. In a step 1012, the call is completed in the standard fashion. 
Once the call is completed, the TFA client 107 then provides an 
acknowledgement message to the gatekeeper 103. In a step 1016, the 
gatekeeper 103 then updates its database to account for the TFA call and its 
bandwidth requirements. Once the TFA call is terminated, the TFA client 107 
sends a termination message T to gatekeeper 103 in step 1018, and 
gatekeeper 103 updates the call and bandwidth information in its database to 
account for the termination of the TFA call. If, in step 1004, bandwidth is 
determined to be unavailable, then gatekeeper 103 sends an error or reject 
message to TFA client 107 in step 1008. 



